Implement the logic that is associated with the steps 5 and 6 in "Figure SAML 2.0 based SSO between LINE WORKS and the customer." The customer SSO system should issue an authorization code and redirect it to the LINE WORKS authentication system after handling its authentication and SSO processes.
It is "AssertionConsumerServiceURL" included in the SAML request passed when the LINE WORKS authentication system requests a login page.
Example) https://LINEWORKSAuthSystemURL/acs/mycompany.com
Caution
- As the ACS URL can change at any time depending on user environments and LINE WORKS's policies, you must use the "AssertionConsumerServiceURL" in the SAML request.
POST
As the ProtocolBinding is "HTTP-POST" in the SAML request, you must use the POST method.
| Parameter | Type | Required | Description |
|---|---|---|---|
| SAMLResponse | String | Y | A character string as specified in the SAML 2.0 response specification (encoded with Base64) |
| RelayState | String | Y | The RelayState value passed when the LINE WORKS authentication system requests a login page. |
<?xml version="1.0" encoding="UTF-8"?><saml2p:Responsexmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" ID="{ID issued by the customer SSO system}"InResponseTo="{ID included in the SAML request }" IssueInstant="{SAML response creation date and time}" Version="2.0"><Signature xmlns=\"http://www.w3.org/2000/09/xmldsig#\"> {Digital signature}</Signature><saml2p:Status><saml2p:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" /></saml2p:Status><saml2:Assertionxmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" ID="{ID issued by the customer SSO system}" IssueInstant="{SAML response creation date and time}" Version="2.0"><saml2:Subject> <saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">{User key of the logged-in user}</saml2:NameID> <saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"> <saml2:SubjectConfirmationData InResponseTo="{ID included in the SAML request }" NotOnOrAfter="{SAML Response end date and time}" Recipient="{ACS URL}" /> </saml2:SubjectConfirmation> </saml2:Subject> <saml2:Conditions NotBefore="{Date and time when the SAML response becomes valid.}" NotOnOrAfter="{SAML response end date and time}"> <saml2:AudienceRestriction> <saml2:Audience>{ACS URL}</saml2:Audience> </saml2:AudienceRestriction> </saml2:Conditions> <saml2:AuthnStatement AuthnInstant="{Date and time when the SAML response is created }" SessionIndex="{ID issued by the customer SSO system}"SessionNotOnOrAfter="{LINE WORKS session expiration date and time}"></saml2:AuthnStatement> </saml2:Assertion></saml2p:Response>The elements are described in the following table.
| Field | Type | Required | Description |
|---|---|---|---|
| Response ID | String | Y | ID issued by the customer SSO system |
| Response InresponseTo | String | Y | ID included in the SAML request |
| Response IssueInstant | Date (UTC) | Y | SAML response creation date and time |
| Signature | String | Y | Digital signature |
| Assertion ID | String | N | ID issued by the customer SSO system |
| Assertion IssueInstant | Date (UTC) | N | SAML response creation date and time |
| Subject NameID | String | Y | User key of the logged-in user (External Key or LINE WORKS Account) |
| SubjectConfirmationData InResponseTo | String | Y | ID included in the SAML request |
| SubjectConfirmationData NotOnOrAfter | Date (UTC) | Y | SAML response start date and time |
| SubjectConfirmationData Recipient | String | Y | ACS URL |
| Conditions NotBefore | Date (UTC) | Y | SAML response start date and time |
| Conditions NotOnOrAfter | Date (UTC) | Y | SAML response end date and time |
| Audience | String | Y | ACS URL |
| AuthnStatement AuthnInstant | Date (UTC) | Y | SAML response creation date and time |
| AuthnStatement SessionIndex | String | Y | ID issued by the customer SSO system |
| AuthnStatement SessionNotOnOrAfter | Date (UTC) | N | Date and time when the LINE WORKS session expires. Note that it can be automatically extended according to LINE WORKS's policies. |
Note
- LINE WORKS's session expires at SessionNotOnOrAfter. Note that it can be automatically extended according to LINE WORKS's policies.
- You can control SessionNotOnOrAfter in different ways, depending on the devices your users have.
- If SessionNotOnOrAfter is not specified, the default login retention period is set to 24 hours (web browser) and 30 days (mobile app and desktop app).
* For the public APIs, the default retention period is 1 hour (web browser), 24 hours (mobile app), and 30 days (desktop app).
<?xml version="1.0" encoding="UTF-8"?><saml2p:Response xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" ID="aidalcbpncbpebcnglhhgkkbojkgbplhhhlecbjb" InResponseTo="gbggljimijodibeomaehmnmjniogjebpjckecbdg" IssueInstant="2018-02-14T10:39:05.956Z" Version="2.0"> <Signature xmlns=\"http://www.w3.org/2000/09/xmldsig#\"> {Digital Signature} </Signature> <saml2p:Status> <saml2p:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" /> </saml2p:Status> <saml2:Assertion xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" ID="pbfijmklioghpbickikmeanhemnmijnmchhibenb" IssueInstant="2018-02-14T10:39:05.956Z" Version="2.0"> <saml2:Subject> <saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">admin@company.com</saml2:NameID> <saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"> <saml2:SubjectConfirmationData InResponseTo="gbggljimijodibeomaehmnmjniogjebpjckecbdg" NotOnOrAfter="2018-02-14T10:44:05.956Z" Recipient="https://auth.worksmobile.com/acs/compay.com" /> </saml2:SubjectConfirmation> </saml2:Subject> <saml2:Conditions NotBefore="2018-02-14T10:39:05.956Z" NotOnOrAfter="2018-02-14T10:44:05.956Z"> <saml2:AudienceRestriction> <saml2:Audience>https://auth.worksmobile.com/acs/company.com</saml2:Audience> </saml2:AudienceRestriction> </saml2:Conditions> <saml2:AuthnStatement AuthnInstant="2018-02-14T10:39:05.956Z" SessionIndex="lepcacjgfnpciekmhhjbeljadfapemdoncmhlkol" SessionNotOnOrAfter="2018-02-15T10:39:05.956Z"> </saml2:AuthnStatement> </saml2:Assertion></saml2p:Response>The following error codes can be returned after LINE WORKS verifies the SAML response.
| Code | Message | Description |
|---|---|---|
| 510 | Invalid SAMLResponse. | Invalid SAMLResponse XML |
| 511 | Signature validation Failed. | Invalid signature |
| 512 | SAMLResponse decoding failed. | Not encoded with Base64 |
| 513 | SAMLResponse inflate failed. | Failed to decompress the SAML response |
| 514 | Signature is missing. | No signature |
| 515 | Invalid SAMLResponse. (StatusCode is not Success) | Invalid SAML response (statusCode error) |
| 520 | Invalid NameID. (520) | Invalid name ID |
| 530 | Works login Failed. (530) | Login failed. |
| 531 | Invalid User. (531) | Name ID (userKey) is not a member of LINE WORKS. |
| 532 | No authority to use. | Not authorized to log in. |
| 534 | Invalid IDC. | Invalid IDC |
| 535 | Invalid Acs Url. | Invalid ACS URL |
| 536 | Certification time is incorrect. | Invalid certification time |
| 537 | Invalid tenant. | Customer not using SSO |
| 551 | Error in IDP API. | Error in the customer's login API |
| 552 | SAMLResponse or RelayState is not exist. | Could not get required data from the customer's Login API. |
| 561 | Unexpected Error. (561) | Unknown error |
| 594 | Login Fail. (594) | Login failed. |
| 595 | Invalid Access. (595) | Invalid access |
| 596 | Invalid Access. (596) | Invalid access |
| 598 | Login Fail. (598) | Failed to get certificates. |
| 599 | Login Fail. (599) | Unknown error |